BBS Toolkit/BBS Toolkit.iso/gt_power/gttutors.zip/DISINFO.TXT

Text File | 1987-06-26 | 23KB | 507 lines

*****************************************************************
Following  is  the  text portion of a 'reply' to  the  series  of
tutorials  that I have constructed and made available to  callers
of  my BBS system on various subjects related to  communications.
This   'reply'  is  from  Chuck  Forsberg,  author   of   ZMODEM.
Throughout  his  original text (which is included  in  full)  are
comments  and clarifications by Paul Meiners and myself.  All  of
our  comments are bracketed between /*...*/ symbols and have  our
names attached to identify source.        --James Davis
                                        [phone] Voice
                                        [phone] Data
*****************************************************************

/*  So far as I know, there have been two fundamental  errors  in
the  content of my tutorials:  the first was that in  an  initial
version  I  indicated that SEAlink protocol used 32-bit  CRC,  it
does  not.  The second is that I inadvertantly  confused  SEAlink
and  Zmodem when discussing the availability of  network-friendly
implementation.   I apologize for the inclusion of these  errors.
In  defense  I can only say that the tutorials  were  constructed
'live'  as the result of capturing my spontaneous responses to  a
series of questions asked by my users, sometimes at 2:00 a.m.  in
the  morning.   Finally,  I have never  claimed  that  Zmodem  is
anything but an excellent example of contemporay protocols and am
dismayed  at  the  crudeness of Mr. Forsberg's  'reply'  and  his
suggestion  that  I  am  'brain  damaged  as  a  result  of  drug
intoxication'  -  a  description  that  my  attorney  is  now  in
possession of.   --James Davis
*/



         Factual Errors in "GTTUTOR" and "MEGAlink" files
                       (Part of COMTUT.ARC)
                Chuck Forsberg omen!caf Rev:6-23-87

Some files connected with a recently released shareware "Powercomm"
communications program have recently come to my attention.

/*
     Let's get it right, the name of the product is "GT PowerComm".

          --Paul Meiners
*/

The "Communications Tutor" files contained in "comtut.arc" are little more
than a sales pitch for a modem program.  These files are so full of errors
and distortions they have minimal didactic value.  They disguise that fact
so well they are carried on many boards that normally reject such blatant
advertising.

/*
     In actual fact, the purpose of the "tutor" files is not to sell
     anything.  The purpose is to try to give a frame of reference to
     confused users.  Something Mr. Forsburg has neglected to do.

          --Paul Meiners
*/

The so-called "tutorial's" claim that CRC-16 increases XMODEM reliability
to near perfect ignores the fact that most XMODEM-CRC file transfer
failures are the result of corruption of XMODEM control sequences that are
*not* protected by a 16 bit CRC.  Omen's "Cybernetic Data Recovery"
catches many of these errors, but some still cause XMODEM failures.  Other
programs do not fare as well.

/*
     Translation: Mr. Forsburg is proud of his product, with some reason.
     However, he neglects the main point, the reliability of any protocol
     is dependent on its implementation.  CRC-16 is a very reliable error
     detection device, when used properly.   Our disk controllers use it
     all the time!

          --Paul Meiners
*/

GTTUTOR confuses YMODEM protocol with XMODEM-1k.  YMODEM, developed in the
early 1980's, preserves both the exact file length and the modification
time of transferred files.  Like XMODEM, XMODEM-1k adds garbage to the end
of files that are not an exact multiple of the protocol's block length.
Since this process is not cumulative, no disk storage space is lost on
today's MSDOS disks where the smallest cluster size is 1k.

/*
     In Mr. Forsburg's original Ymodem specifications, from which I wrote
     the protocol drivers for "GT PowerComm", there is no reference to an
     Xmodem-1k.  In the original documentation, supplied by Mr. Forsburg,
     the specification is given for two forms of Ymodem.  A simple Xmodem
     extension, which he now calls Xmodem-1k, and a batch version.  In that
     document both protocols are referred to as Ymodem.

          --Paul Meiners
*/

Having missed the point about YMODEM, GTTUTOR goes on to describe how
their "1K Telink" protocol downshifts from 1024 byte to 128 byte blocks
when encountering a set of 6 errors.  Thank Heavens they didn't call it
"ymodem".  The GTTUTOR file fails to mention that YMODEM.DOC specifically
forbids this form of downshifting because changing the size of an
unacknowledged block allows data errors to escape detection by the CRC.

/*
     Really.  It sounds like Mr. Forsburg has not read his own documentation.
     On page 7 of his 1985 description of Ymodem Batch, he gives a detailed
     example of how to mix 1024 and 128 byte packets.  This is just becoming
     too silly.  Does Mr. Forsburg expect this to be taken seriously?

     One does not change the size of a packet that has not been Ack'ed.  You
     shift to smaller packets ONLY after all outstanding packets have finally
     been Ack'ed.  To suggest otherwise is too foolish for words.

     The fact is well recognized in the field that smaller packets have a
     better chance on noisy lines.  This is not didactic, but empirical.

          --Paul Meiners
*/

Most intriguing is the comment that ZMODEM is slow.  This comes as a great
surprise to ZCOMM and Pro-YAM users who routinely get throughputs better
than 18000 bps when transferring files to PC-XT class machines from Unix.
Telebit TrailBlazer modem users who download files from TeleGodzilla over
wretched (Thanks, PNB) phone lines with throughputs up to 1350 characters
per second would join in the laughter.

/*   Fact, in the first series of tests that we ran of Zmodem  we
were  disappointed in the performance we obtained.   Having  been
told to expect 99% transmission efficiencies and realizing  about
90%  during  our tests I found it was slower  than  expected  and
certainly  slower than Ymodem which I described as the  'King  of
performance'.  The second tutorial was produced many weeks  later
after  we had been successful in some new tests (because  we  had
obtained  a working and more efficient version of DSZ.EXE) and  I
then  pointed out that Zmodem was indeed very fast, though  still
not as fast as Ymodem.  --James Davis
*/

/*
     Unfortunately, most of us do not have Telebit TrailBlazer's.  The
     simple fact is that Mr. Forsburg measures performance by the number
     of bytes sent down the tube in a unit of time.  This is very misleading.
     The performance as measured in "GT PowerComm" is taken by dividing
     the size of the file by the time of transmission.  This takes into
     account the cost of overhead.  Like escaped control characters.  Mr.
     Forsburg would have us believe that escaped control characters have
     no effect on performance.  But I know better, because I pay the phone
     bill.

          --Paul Meiners
*/

GTTUTOR's claim that ZMODEM is too slow is especially puzzling because it
later claims ZMODEM fails to operate with 9600 bps buffered modems because
it is too fast!!  So here we have a protocol that is both too slow and too
fast.  The relevant word isn't "slow" or "fast", it's "bogus".

/*

     Mr. Forsburg continues to display his misunderstanding.  Zmodem transmits
     bytes fast.  There has never been a claim to the contrary.  It merely
     transmits files slowly.  Any protocol that uses escaped characters,
     transmits files more slowly than more optimized protocols.  For example,
     SEAlink has a better performance rating than Zmodem, because it escapes
     no control characters at all.

          --Paul Meiners
*/

GTTUTOR further states that ZMODEM uses 256 byte blocks.  In actuality,
ZMODEM uses a variable subpacket length up to 1024 bytes.  A ZMODEM data
frame can encompass an entire file.

/*
     Mr. Davis misunderstood.  Which is forgivable considering the complexity
     of Mr. Forsburg's documentation.  Byzantine is too kind a characterization.

          --Paul Meiners
*/

Davis mentions that ZMODEM is "not a protocol that is written into a
program like GT".  Considering how little Davis understands about
ZMODEM, that is indeed fortunate.

/*
     I restate, I would very much like to have Zmodem internal to GT, but
     find I lack the required time to accomplish the task.  Largely due to
     the Byzantine nature of Mr. Forsburg's documentation.  A fine protocol
     that suffers from verbose documentation.

          --Paul Meiners
*/

Davis mentions he twice called his "powercomm" "procomm" in his
documentation.  He contemplates how embarrassed he would have been if the
documentation had been released that way.  So, he took POLYTRON's PowerCom
trademark, doubled the "m" letter, and called his program that.

/*
     The name of the product is "GT PowerComm".  It is not Mr. Davis'.
     It is mine.

          --Paul Meiners
*/

When mentioning that SEALINK is becoming popular because the Opus BBS
system supports it, GTTUTOR fails to mention that Opus now supports ZMODEM
as well.

/*
     The new version of Opus, at this writing, is still in beta test.
     It will support Zmodem, which is a much better protocol than SEAlink.
     I am very happy to see this happen.  Wish everyone supported Zmodem.

          --Paul Meiners
*/

GTTUTOR complains that ZMODEM requires ten Ctrl-X's in a row to abort a
transfer.  As with many observations in these files, this observation is
wide of the mark, ZMODEM only requires five.  If Davis had read the ZMODEM
Protocol Description before flaming, he would have noticed the comment
that ZMODEM originally required only two Ctrl-X's in a row to abort, but
this was changed to five because several transfers had failed when line
noise generated two Ctrl-X characters in a row.

/*
     To be absolutely honest, DSZ gets changes so often that it is
     impossible to keep up with it.  There are many BBS's that run
     DSZ and warn you to use "Ten Ctrl-X to cancel...".  If this has
     changed or was incorrect, I apologize.

          --Paul Meiners
*/

GTTUTOR further claims: "Because it is not network friendly it (ZMODEM)
does not bother with (doesn't have to) escape coding anything.  This is
probably a fatal mistake to its future particularly as the networks get
crowded." Such a comment makes one wonder if the author had ever read the
ZMODEM Protocol Description except perhaps while brain damaged from drug
intoxication.  Again, reality has little to do with GTTUTOR's world;
ZMODEM escapes all the network control characters used by the major
PSVANs, and has an option to escape all control characters.  If
"powercomm's" MEGAlink protocol is implemented according to its April 18
document, it is much less network friendly than ZMODEM.

/*
     This is such drivel.  Zmodem is obviously network friendly.  Where
     did he get the idea that we claimed otherwise.  This is beneath
     comment.

          --Paul Meiners
*/

/*  As my opening comments pointed out, I inadvertantly described
SEAlink  as  being Network friendly and Zmodem as not  being  so.
Mr. Meiners has not made any such comments and apparantly has not
seen that particular tutorial.  My error and I will correct it.
-- James Davis
*/

GTTUTOR closes with a section on high speed (>2400 bps) modems.  It should
come as no surprise that Davis still hates ZMODEM, not bothering to set
DSZ and the modem to use the same flow control method.  Remember, this is
the same ZMODEM protocol that is too slow for slow modems, or so we were
told.

/*
     Where does he get the idea that Mr. Davis "hates Zmodem"?  This could
     not be further from the truth.  Mr. Davis and I have the greatest
     respect for Zmodem (although my respect for Mr. Forsburg is slipping
     a little right now).  I remember that Mr. Davis even talked me into
     continuing support for Zmodem when I threatened to drop it due to
     Mr. Forsburg's incessant releases of DSZ.  He doesn't even have a
     version number for DSZ, just uses the date for a version number!
     Kind of makes life hard for developers trying to keep up with him.
     Zmodem is a fine protocol.  The premier protocol in the field today.
     Nobody hates it.  What a weird idea.

          --Paul Meiners
*/

You'd think that a tutorial on data communications might have mentioned
there are two methods of flow control.  A tutorial might have mentioned
what this means in practical terms.  For example, hardware flow control
locks up communications unless the cabling is exactly correct (which it
usually isn't).  That's why Pro-YAM, ZCOMM, DSZ, most networks and modems
default to software flow control.  But for this test, nobody bothered to
use the defaults.

/*
     Note: If your cabling is not correct, you are sure to have lots and
     lots of troubles.  Beyond any simple problem with flow control.  You
     and all modem users better make sure that their cables and modems are
     installed correctly.  No end of problems will be the result otherwise.
     Geez, I thought everyone knew that there is no substitute for proper
     installation.

          --Paul Meiners
*/

Here is an updated version of the speeds using 9600 bps transmission, with
the ZMODEM test using TrailBlazer modems with a 9600 bps interface speed
(better results are obtained at 19200 bps).  The ZMODEM results show a
473104 byte ASCII file transferred over a phone line to an IBM PC with an
XT class hard disk.

       WXmodem   60.4 % efficiency  580 cps
       SEAlink   75.6 %             725 cps
       Ymodem    77.6 %             744 cps
       MegaLink  98.5 %             945 cps
       ************************************
       Zmodem    98.8 %             948 cps

/*    This   additional  'test'  is  impossible!   It   is   also
meaningless.  Mr. Forsberg did not use the exact same hardware as
I  did,  did not have controlled environments on both ends  as  I
did,  and WORST OF ALL he could not possibly have sent  the  same
file that I sent in each of the tests that I ran.  For those that
read  the  tutorial you know that every file will  have  its  own
unique  performance with network friendly protocols because  they
have variable numbers of bytes that may need to be escape  coded.
Further, the file size affects how significantly overhead factors
into  total  transfer  efficiency.  Mr. Forsberg  could  just  as
easily have said that Zmodem developed performance of 960 cps and
it would have been just as credible.   Finally, he claims to have
sent  an  ASCII file of 473,104 bytes.  I used  an  800,000  byte
ARCed  file  in  order to  ELIMINATE   the  hardware  compression
efficiency that intelligent modems are capable of providing.  His
test  may well have indicated that his modem is quite  efficient,
but it says NOTHING about Zmodem relative to the other protocols.
--James Davis
*/

Contrary to GTTUTOR's earlier claims of ZMODEM lethargy, DSZ on an XT, let
alone an AT, is fast enough to overdrive a high speed modem when flow
control is mismatched.  DSZ, ZCOMM, Pro-YAM and PowerCom default to
XON/XOFF flow control, as do TELEBIT TrailBlazer and many other buffered
modems.  They work properly, even when using a 19200 bps interface speed
and a 300 bps modem connection.  ZMODEM programs have been used with
TrailBlazer, Fastcomm, MNP, Data Race, and other buffered modems.  In
fact, Pro-YAM's experience with high speed modems is so extensive that
Pro-YAM includes special code to work around a subtle firmware bug in some
of the modems.

/*
     First, MegaLink supports both forms of flow control.  Second, many
     circumstances require BOTH forms of control to be used simultaneously.
     MegaLink supports this as well.  The whole issue of flow control is
     a "red herring" on Mr. Forsburg's part.  I am beginning not to take
     this document seriously.

          --Paul Meiners
*/


                        MEGAlink

MEGAlink is claimed to be a fast, inexpensive, and reliable file transfer
protocol.

/*
     I have not claimed this.  This was my goal.  I let others describe
     whether or not I have attained my goal.  Being somewhat more modest
     than Mr. Forsburg.

          --Paul Meiners
*/

The MEGAlink description identifies ZMODEM as the ideal protocol, fast and
reliable (it is), but expensive (i.e., non trivial) to implement.  (ZMODEM
protocol software is available in PUBLIC DOMAIN C source code.) Since most
of the problems in porting ZMODEM to a new system arise from the
concurrency of data transmission and compiler bugs affecting the CRC
calculations, MEGAlink offers no advantage here unless one's only compiler
is Turbo Pascal.  Now that Turbo C can be bought for less than $60.00,
what's the big deal already?

/*
     There are several "big deals".  First, Mr. Forsburg does not deny that
     Zmodem is non trivial to implement.  That is indeed a "big deal", as
     one the goals of most PD protocol designers, all the way back to Ward
     Christiansen, is simplicity of design.

     The second "big deal" is that the world does not begin and end with
     C.  There are quite a few other languages out there.  It seems that
     Mr. Forsburg is rather pompous, considering Zmodem written once and
     for all, because it is coded in C.

          --Paul Meiners
*/

MEGAlink claims to use the Jennings Telink header block format.  The
header block described actually resembles the SEAlink header block, which
is different from and incompatible with the Telink header.

/*
     MegaLink does use the Telink header block.  As does SEAlink, by the
     way.  This is simply a misstatement of fact by Mr. Forsburg.

          --Paul Meiners
*/

The developer(s) of MEGAlink did not read the ZMODEM protocol description
carefully, or they would not have repeated so many of the design errors of
previous protocols that were identified in the ZMODEM document.

/*
     What Mr. Forsburg considers design errors, I prefer to call
     simplifications.

          --Paul Meiners
*/

In addition to repeating many of the mistakes that were identified and
avoided in the design of ZMODEM, MEGAlink's author(s) make a number of
false statements about ZMODEM.

/*
     That could be.  The only thing I have ever said about Zmodem is
     that it is a fine protocol and rather difficult to implement.

          --Paul Meiners
*/

MEGAlink offers no advantages over the well designed ZMODEM protocol
except as a vehicle to hype the "powercomm" program.

/*
     I gave Mr. Forsburg his due.  But the fact remains that neither
     Zmodem or MegaLink are easy to implement.  Ask John Friel, author
     of Qmodem.  MegaLink offers a distinct advantage to the implementor.
     It offers a structure based on packets.  A structure that any author
     who has done Xmodem, should feel comfortable with.  Obviously, Mr.
     Forsburg has different opinions.  Zmodem's primary asset is DSZ. An
     excellent implementation of a difficult protocol.  Zmodem is made
     more difficult by Mr. Forsburg's steadfast refusal to stop fiddling
     with it.  And by the fact that his documentation of it verbose, so
     verbose that it is indeed very easy to miss the point.

          --Paul Meiners
*/

Before filling up disk quotas and phone lines with bleeding about the
"MEGAlink" protocol, MEGAlink's authors should have taken the time to
understand the workings of ZMODEM.  They could have implemented a useful,
user friendly, robust, efficient, well thought out protocol instead of
MEGAlink.

/*
     Mr. Davis is not the author of "GT PowerComm", nor is he the
     designer of MegaLink.  I am.

          --Paul Meiners
*/

A careful reading of the ZMODEM description would also have resulted in
correct spelling of names and a realization that the recently released
shareware program should not infringe on Polytron INC's "PowerCom"
trademark.

/*
     "GT PowerComm" is not a "recently released shareware program".  It
     is currently in version 12.21.  After nearly 3 years of development
     and distribution.  Where did he get his facts?

     I am coming to the conclusion that Mr. Forsburg's opinions have litte
     to do with reality as the rest of us know it.

          --Paul Meiners
*/

If you come across these files, pass them on to your communications guru
friends for some good chuckles.  The Pascal dialect CRC calculations are
priceless.  But please don't give these cleverly disguised sales pitches to
the incognoscenti without a ton of salt.

/*
     The CRC calculator used in "GT PowerComm" are written in MASM, not
     Turbo Pascal, as Mr. Forsburg indicates.  Another final misstatement.

          --Paul Meiners
*/

Chuck Forsberg WA7KGX Author of Pro-YAM communications Tools for PCDOS and Unix
...!tektronix!reed!omen!caf  Omen Technology Inc "The High Reliability Software"
  17505-V Northwest Sauvie Island Road Portland OR 97231  Voice: 503-621-3406
TeleGodzilla BBS: 621-3746 2400/1200  CIS:70007,2304  Genie:CAF  Source:TCE022
  omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
  omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly


June 26, 1987

I have a very hard time taking this document seriously.  I have gone thru it
and tried to make return comments by bracketing them with the C comment markers.
/* .... */   Anything between these marks are my comments, not Mr. Davis' or
Mr. Forsburg's.  I consider this whole document rather a bad case of "sour
grapes" on Mr. Forsburg's part.  And am quite surprised that he distributed
it publicly.  But I consider it an opportunity.  An opportunity to set the
record straight.  Of course, it is indicative of the fact that we have come
to the "great ones" attention.  A sign that we have arrived, so to speak.

Regards,

Paul Meiners

GT PowerComm Author                            [phone] Data
MegaLink Designer                              [phone] Voice